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(57) Abstract 

An electronic monetary system 
provides for transactions utilizing an 
dectronic -monetary system that emulates 
a wallet or a purse that Is customarily 
used for keeping money, credit cards 
and other forms of payment organized. 
Access to the instruments in the wallet or 
purse is restricted by a password to avoid 
unauthorized payments. A certificate 
form must be completed in order to 
obtain an instrument The certificate 
form obtains the information necessary 
for creating a certificate granting 
authority to utilize an instrument, a 
payment holder and a complete dectronic 
wallet, Electronic approval results in the 
generation of an electronic transaction to 
complete the order. If a user selects a 
particular certificate, a particular payment 
instrument holder will be generated based 
on the selected certificate. In addition, 
a default bitmap, for the instrument 
associated with a particular certificate 
is defined by the issuing agent for the 
certificate, and the default bitmap will be 
displayed when the certificate definition 
is completed. Finally, the number 
associated with a particular certificate 
will be utilized to determine if a certificate 
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A SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR 
NETWORK ELECTRONIC PAYMENT AND CREDIT COLLECTION 
UTILIZING A PAYMENT INSTRUMENT AND CERTIFICATION OF 



The present invention relates to the electronic payment in exchange 
for goods and services purchased over a communication network, and 
more specifically, it relates to an ergonomic, graphical user network 
10 interface which simulates a real life transaction for the credit card, 
cash or other payment of goods. 



The present invention relates to an electronic graphical representation 
15 of a monetary system for implementing electronic money payments as 
an alternative medium of economic exchange to cash, checks, credit 
and debit cards, and electronic funds transfer. The Electronic- 
Monetary System is a hybrid of currency, check, card payment 
systems, and electronic funds transfer systems, possessing many of 
20 the benefits of these systems with few of their limitations. The system 
utilizes electronic representations of money which are designed to be 
universally accepted and exchanged as economic value by subscribers 
of the monetary system. 

25 Today, approximately 350 billion coin and currency transactions 

occur between individuals and institutions every year. The extensive 
use of coin and currency transactions has limited the automation of 
individual transactions such as purchases, fares, and bank account 
deposits and withdrawals. Individual cash transactions are burdened 

30 by the need to have the correct amount of cash or providing change 
therefor. Furthermore, the handling and managing of paper cash and 
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Moreover, ACH transactions usually cannot be performed during off 
business hours. 

Home Banking bill payment services are examples of an EFT system 
5 used by individuals to make payments from a home computer. 

Currently, home banking initiatives have found few customers. Of the 
banks that have offered services for payments, account transfers and 
information over the telephone lines using personal computers, less 
than one percent of the bank's customers are using the service. One 
10 reason that Home Banking has not been a successful product is 

because the customer cannot deposit and withdraw money as needed 
in this type of system. 

Current EFT systems, credit cards, or debit cards, which are used in 
15 conjunction with an on-line system to transfer money between 

accounts, such as between the account of a merchant and that of a 
customer, cannot satisfy the need for an automated transaction 
system providing an ergonomic interface. Examples of EFT systems 
which provide non-ergonomic interfaces are disclosed in US Patents 
20 Numbers 5.476,259; 5,459,304; 5,452,352; 5,448,045; 5,478,993; 
5,455,407; 5,453,601; 5,465,291; and 5,485,510. 

To implement an automated, convenient transaction that can 
dispense some form of economic value, there has been a trend 

25 towards off-line payments. For example, numerous ideas have been 
proposed for some form of "electronic money" that can be used in 
cashless payment transactions as alternatives to the traditional 
currency and check types of payment systems. See U.S. Pat. No. 
4,977,595, entitled "METHOD AND APPARATUS FOR IMPLEMENTING 

30 ELECTRONIC CASH," and U.S. Pat. No. 4,305,059, entitled 
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purse, a smart card, a pocketbook, a checkbook, a satchel or other 
payment instrument holder that is customarily used for storing 
money, credit cards and other payment instruments. Access to the 
wallet is restricted by a password, which can be encrypted, or used to 
5 generate an encryption key for restricting access to sensitive 
information, to avoid unauthorized payments. When access is 
authorized, a graphical representation (bitmap) of the instruments) is 
presented on the display based on either a user default, an 
instrument issuer default or payment instrument holder default to 

10 enable a user to select a payment instrument for use in a particular 
transaction. Once a payment instrument is selected, a summary of 
the goods for purchase are presented to the user and the user enters 
their electronic approval for the transaction or cancels the 
transaction. Electronic approval results in the generation of an 

15 electronic transaction to complete the order. If a user selects a 

particular certificate, a particular payment instrument holder will be 
generated based on the selected certificate. In addition, a default 
bitmap for the instrument associated with a particular certificate is 
defined by the issuing agent for the certificate, and the default bitmap 

20 will be displayed when the certificate definition is completed. Finally, 
the number associated with a particular certificate will be utilized to 
determine if a certificate can be issued by a particular party. 
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Figure 7 is a flowchart of the detailed logic associated with the 
administration mode of the paywindow in accordance with a preferred 
embodiment; 

Figure 8 is a flowchart of administration mode processing associated 
with register and report processing in accordance with a preferred 
embodiment; 

Figure 9 is an illustration of a paywindow display in accordance with 
a preferred embodiment; 

Figure lO illustrates a list of payment methods for a user to select 
from in accordance with a preferred embodiment; 

Figure 11 is an authorization display screen in accordance with a 
preferred embodiment; 

Figure 12 is a PAID authorization display screen in accordance with a 
preferred embodiment; 

Figure 13 is a cancellation of authorization display screen in 
accordance with a preferred embodiment; 

Figure 14 illustrates a Main screen in accordance with a preferred 
embodiment of the invention; 

Figure 15 is an illustration of an Administration display screen in 
accordance with a preferred embodiment; 
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Figure 26 illustrates a report customize display in accordance with a 
preferred embodiment; 

5 Figure 27 is a report output display in accordance with a preferred 
embodiment; 

Figure 28 illustrates a set of images illustrating "open" and "closed" 
icons for payment holders in accordance with a preferred embodiment; 

10 

Figure 29 is an illustration of a certificate issuance form in 
accordance with a preferred embodiment; 

Figure 30 illustrates a certificate issuance response in accordance 
15 with a preferred embodiment; 

Figure 31 illustrates a collection of payment instrument holders in 
accordance with a preferred embodiment; 

20 Figure 32 illustrates the default payment instrument bitmap in 
accordance with a preferred embodiment; 

Figure 33 illustrates a selected payment instrument with a fill in the 
blanks for the cardholder in accordance with a preferred embodiment; 
25 and 



Figure 34 illustrates a coffee purchase utilizing the newly defined 
VISA card in accordance with a preferred embodiment of the 
invention. 

30 
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need to be adapted to make use of the benefits of OOP. A need exists 
for these principles of OOP to be applied to a messaging interface of an 
electronic messaging system such that a set of OOP classes and 
objects for the messaging interface can be provided. 

5 

OOP is a process of developing computer software using objects, 
including the steps of analyzing the problem, designing the system, 
and constructing the program. An object is a software package that 
contains both data and a collection of related structures and 

10 procedures. Since it contains both data and a collection of structures 
and procedures, it can be visualized as a self-sufficient component 
that does not require other additional structures, procedures or data 
to perform its specific task. OOP, therefore, views a computer 
program as a collection of largely autonomous components, called 

1 5 objects, each of which is responsible for a specific task. This concept 
of packaging data, structures, and procedures together in one 
component or module is called encapsulation. 



In general, OOP components are reusable software modules which 
20 present an interface that conforms to an object model and which are 
accessed at run-time through a component integration architecture. 
A component integration architecture is a set of architecture 
mechanisms which allow software modules in different process spaces 
to utilize each others capabilities or functions. This is generally done 
25 by assuming a common component object model on which to build the 
architecture. 

It is worthwhile to differentiate between an object and a class of 
objects at this point. An object is a single instance of the class of 
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which are typically different from those associated with a metal piston. 
It skips over the original and uses new functions related to ceramic 
pistons. Different kinds of piston engines will have different 
characteristics, but may have the same underlying functions 
5 associates with it (e.g., how many pistons in the engine, ignition 

sequences, lubrication, etc.). To access each of these functions in any 
piston engine object, a programmer would call the same functions 
with the same names, but each type of piston engine may have 
different/ overriding implementations of functions behind the same 
10 name. This ability to hide different implementations of a function 

behind the same name is called polymorphism and it greatly simplifies 
communication among objects. 

With the concepts of composition-relationship, encapsulation, 
1 5 inheritance and polymorphism, an object can represent just about 

anything in the real world. In fact, our logical perception of the reality 
is the only limit on determining the kinds of things that can become 
objects in object-oriented software. Some typical categories are as 
follows: 

20 

• Objects can represent physical objects, such as automobiles in 
a traffic-flow simulation, electrical components in a circuit-design 
program, countries in an economics model, or aircraft in an air- traffic- 
control system. 

25 

• Objects can represent elements of the computer-user 
environment such as windows, menus or graphics objects. 

• An object can represent an inventory, such as a personnel file or 
30 a table of the latitudes and longitudes of cities. 
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composition-relationship. With the advent of the C++ language, many 
commercial software developers have embraced OOP. C++ is an OOP 
language that offers a fast, machine-executable code. Furthermore, 
C++ is suitable for both commercial-application and systems- 

5 programming projects. For now, C++ appears to be the most popular 
choice among many OOP programmers, but there is a host of other 
OOP languages, such as Smalltalk, common lisp object system 
(CLOS), and Eiffel. Additionally, OOP capabilities are being added to 
more traditional popular computer programming languages such as 

10 Pascal. 



The benefits of object classes can be summarized, as follows: 

♦ Objects and their corresponding classes break down complex 
1 5 programming problems into many smaller, simpler problems. 

Encapsulation enforces data abstraction through the 
organization of data into small, independent objects that can 
communicate with each other. Encapsulation protects the data in an 
20 object from accidental damage, but allows other objects to interact 
with that data by calling the object's member functions and 
structures. 



Subclassing and inheritance make it possible to extend and 
25 modify objects through deriving new kinds of objects from the 

standard classes available in the system. Thus, new capabilities are 
created without having to start from scratch. 

• Polymorphism and multiple inheritance make it possible for 
30 different programmers to mix and match characteristics of many 
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Class libraries are very flexible. As programs grow more complex, 
more programmers are forced to reinvent basic solutions to basic 
problems over and over again. A relatively new extension of the class 
library concept is to have a framework of class libraries. This 
5 framework is more complex and consists of significant collections of 
collaborating classes that capture both the small scale patterns and 
major mechanisms that implement the common requirements and 
design in a specific application domain. They were first developed to 
free application programmers from the chores involved in displaying 
10 menus, windows, dialog boxes, and other standard user interface 
elements for personal computers. 

Frameworks also represent a change in the way programmers think 
about the interaction between the code they write and code written by 

15 others. In the early days of procedural programming, the programmer 
called libraries provided by the operating system to perform certain 
tasks, but basically the program executed down the page from start to 
finish, and the programmer was solely responsible for the flow of 
control. This was appropriate for printing out paychecks, calculating 

20 a mathematical table, or solving other problems with a program that 
executed in just one way. 

The development of graphical user interfaces began to turn this 
procedural programming arrangement inside out. These interfaces 

25 allow the user, rather than program logic, to drive the program and 
decide when certain actions should be performed. Today, most 
personal computer software accomplishes this by means of an event 
loop which monitors the mouse, keyboard, and other sources of 
external events and calls the appropriate parts of the programmer's 

30 code according to actions that the user performs. The programmer no 
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supports copy and paste. and so on, the programmer can a,so 
relinquish control ,„ a greater degree than even, ,„„p p^s 
permit. The framework code takes care of a,mos, a,, even, handiing 
and flow of control. M d the programmer, code ,s called on* when the 
framework needs it (e.e to create ^ ™ * , 
30 structure,. ' *°*~*> *™ 
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A programmer writing a framework program not only relinquishes 
control to the user (as is also true for event loop programs), but also 
relinquishes the detailed flow of control within the program to the 
5 framework. This approach allows the creation of more complex 

systems that work together in interesting ways, as opposed to isolated 
programs, having custom code, being created over and over again for 
similar problems. 

10 Thus, as is explained above, a framework basically is a collection of 
cooperating classes that make up a reusable design solution for a 
given problem domain. It typically includes objects that provide 
default behavior (e.g., for menus and windows), and programmers use 
it by inheriting some of that default behavior and overriding other 

15 behavior so that the framework calls application code at the 
appropriate times. 

There are three main differences between frameworks and class 
libraries: 

20 

• Behavior versus protocol Class libraries are essentially 
collections of behaviors that you can call when you want those 
individual behaviors in your program. A framework, on the other 
hand, provides not only behavior but also the protocol or set of rules 
25 that govern the ways in which behaviors can be combined, including 
rules for what a programmer is supposed to provide versus what the 
framework provides. 

Call versus override. With a class library, the code the 
30 programmer instantiates objects and calls their member functions. 
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Information Processing Text and Office Systems; Standard 
Generalized Markup Language (SGML). 



To date, Web development tools have been limited in their ability to 
5 create dynamic Web applications which span from client to server and 

interoperate with existing computing resources. Until recently, HTML 

has been the dominant technology used in development of Web-based 

solutions. However, HTML has proven to be inadequate in the 

following areas: 
10 o Poor performance; 

o Restricted user interface capabilities; 

o Can only produce static Web pages; 

o Lack of interoperability with existing applications and data; and 
o Inability to scale. 
15 Sun Microsystem's Java language solves many of the client-side 
problems by: 

o Improving performance on the client side; 

o Enabling the creation of dynamic, real-time Web applications; 

and 

20 o Providing the ability to create a wide variety of user interface 
components. 

With Java, developers can create robust User Interface (UI) 
components. Custom "widgets" (e.g. real-time stock tickers, animated 
icons, etc.) can be created, and client-side performance is improved. 
25 Unlike HTML, Java supports the notion of client-side validation, 
offloading appropriate processing onto the client for improved 
performance. Dynamic, real-time Web pages can be created. Using 
the above-mentioned custom UI components, dynamic Web pages can 
also be created. 
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applications. One of ordinary skill in the art will readily recognize that 
ActiveX could be substituted for JAVA without undue experimentation 
to practice the invention. 



5 Figure IB is a block diagram of a preferred embodiment of the system 
utilizing native code. The major components of the system are 
described below with reference to Figure IB. The mechant web site 
180 contains the shopping Common Gateway Interface (CGI) 190 
which is provided by the merchant or other web server communication 

10 system. The CGI is an interface which allows applications to access, 
process and respond to incoming messages. Industry slang is to refer 
to CGI scripts as a way of saying that a programmer is writing web 
server applications in scripting languages. A CGI script is a type of 
software application program. Merchants typically are setup with 

15 programs for authorization that are made up of CGI scripts. A 

certificate of authority will also have a web server and the handling of 
certificate requests will utilize CGI scripts. Consumers interact with 
this system to shop at the merchant site. The merchant system also 
accepts payment transactions originating from the consumer using 

20 the PayWindow helper application. The payment instruction 192 is a 
file representing the Multipurpose Internet Mail Extension (MIME) 
message that is created by the merchant system when the consumer 
elects to pay. This MIME message contains the order information and 
the payment instructions which are specific to the merchant. The 

25 order information contains the Goods and Services Order (GSO), 
shipping address, merchant Uniform Resource Locator (URL), 
merchant certificate, merchant name and address, and transaction ID 
associated with the order. The payment instructions contains the 
payment instruments that the merchant accepts and the payment 

30 protocol preferences. 
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information, the system issues a certificate along with a payment 
instrument to the consumer. 

The Single Account Wallet 160 at the bank web site 182 represents 
5 the MIME message that is created by the Certificate Issuance system. 
This MIME message contains a VeriFone wallet. The VeriFone wallet 
contains a single payment instrument and the certificate associated 
with it For security reasons, the private key is not included in the 
wallet. The has to specify a private key before using the instrument for 
10 payment. When the consumer is issued the certificate, this MIME 
message is sent to the browser. The browser launches the Certificate 
Installation application 174, 144 which is defined as a helper 
application in the browser. The Certificate Installation application 
174, 144 reads the MIME message and install the wallet into the 
15 wallet database 158. 



Various helper applications 198, 172, 174, 176 are provided to make 
the consumer's shopping experience easy and efficient including the 
following helper applications. The Paywindow helper application 188 

20 is utilized by the consumer to authorize the payment to the merchant, 
to administer their wallets, to review their previously completed 
payment transactions and to perform housekeeping activities on the 
wallets. This application is defined as a 'helper' application on the 
consumer's desktop. The browser launches this application when the 

25 merchant system sends a MIME message requesting payment. 

The PayWindow Setup Helper application 172 is used by the 
consumer to install helper applications and other modules from the 
web site onto the consumer desktop. When a consumer attempts to 
30 install an application for a first time, the consumer does not have a 
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downloaded and installed by the consumer on his or her desktop. 
Thereafter the Setup Helper application 172 automatically installs 
future releases of helper applications or other software modules. 

5 Whereas an address requisition is presented as an embodiment, one 
of ordinary skill in the art will readily comprehend that clothing sizes, 
music preferences, mother's name or other information to assist a 
merchant can also be uploaded via similar means without departing 
from this embodiment. 

Figure 2 provides an alternative preferred embodiment in accordance 
with a Java based implementation of the invention. Java is a network 
application enabler for applications that utilize the Internet and 
HTML. Java is an object-oriented langugage that was developed by 
15 Sun Microsystems to speed development of their network applications. 



Only the differences between the native embodiment discussed earlier 
20 and the Java version is addressed to clarify the discussion. A 

Payment Instruction Applet 200 at the Merchant Web Site 180 is 
responsible for delivering the order information to the PayWindow 
Applet 210, 230 on the consumer's desktop 186. This order 
information has the same information that is contained in the 
25 Payment Instruction MIME message which was described in the 
PayWindow System View Native Code section. 

The applet is a part of the payment HTML 192 page which is displayed 
by the merchant to the consumer. The applet requires that the 
30 following parameters be set with appropriate data when the payment 
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Page is generated by the merchant system GSO. Shipping Address 
Merchant, Merchant Certificate. Merchant URL and Button Text The 
applet 200 displays a button called "Pay-. "Use PayWindow" or the 
va,ue of the Button Text parameter. Once clicked, the app.et delivers 
the above mformation to the PayWindow applet on the consumer's 
desktop. The consumer interacts with the PayWindow 210 A PP ,et to 
complete the payment transaction. 



20 



25 



30 



The Address Requisition A PP ,et 204 at the Merchant Web Site 180 is 
• utilised by the merchant system 180 to obtain a consumer, shipping 
and/or billing address. This applet is displayed on the HTML page 
wbch accepts the consumer's shipping or billing address. The applet 
delays a button called -V-wallet" or the value of the Button Text 
parameter. Once clicked, the app.et 204 .aunches the AddressWindow 
applet 214 utilizing the consumer's address. The AddressWindow 
applet 214 interacts with the consumer and send the address 
mformation to the merchant system 180. The address information is 
then processed consistent with the processing in the native system. 

The Certificate Issuance CGI scripts 162 and the Single Account 
Wallet 160 at the Bank Web Site 182 is processed as described in the 
nauve system. The Certificate Installation Applet 220 of the Bank 
Web Site 182 is utilized by the Certificate Issuance CGI scripts 162 
system to deliver a consumer's certificate to the consumer's desktop. 

A variety of applets are provided at a web site to make the consumer's 
■hopping experience easy and efficient. These helper applications 
include a Setup Applet 212. PayWindow Applet 210 and an 
AddressWindow Applet 214 similar to the PayWindow Helper 
Application Native section discussed above. 
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Figure 3 is an architecture block diagram in accordance with a 
preferred embodiment of the subject invention. Processing 
commences at function block 300 where the Graphical User Interface 
(GUI) part of the application is initialized. The GUI application 300 
provides the consumer with support for ordering and making 
payments during the shopping process. There are also GUI 
components provided for wallet creation; importing, certificate and 
payment method creation and maintenance; and for transaction 
register review and reporting. The screen designs, and their 
associated logic, for the helper applications and applets are 
individually discussed in detail below. 



10 



The Certificate Manager 304 manages the automatic downloading of a 
15 consumer's certificate from a bank, validation of a consumer's and a 
merchant's certificates and automatic requisition of certificate 



20 



25 



renewal. 



30 



The Payment Manager 306 coordinates and completes the payment 
request that is received from the merchant system. The payment 
request is received via a MIME message in the native code 
implementation or via an applet in the Java implementation. The 
payment request received contains the final GSO, Ship-To name, 
merchant certificate, merchant URL. coupons and the payment ' 
amount. The manager 306 then communicates with the payment 
related GUI component to interact with the consumer to authorize and 
complete the payment transaction. The manager is also responsible 
for determining the payment.protocol based on the consumer's 
payment instrument and the merchant's preferred payment protocol. 
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The manager 306 includes a well defined Application Programming 
Interface (API) which enables OEMs to interface with the payment 
manager 306 to make payments to specific HTTP sites. The detailed 
logic associated with the payment manager 306 is presented in Figure 



10 



15 



20 



The payment manager 306 enforces standard operations in the 
payment process. For example the receipt and the transaction record 
can automatically be transferred to the Wallet file once the payment is 
completed. The payment manager architecture in accordance with a 
preferred embodiment is presented in Figure 4. A user interfaces with 
the payment manager 430 via a user interface 400 that responds to 
and sends a variety of transactions 410, 408. 406, 404 and 402. The 
transactions include obtaining the next record, payment record, 
receipt, acceptance of the payment instrument and GSO components. 
In turn, the payment manager 430 sends transactions 414 and 
receipts 420 to the wallet manager 422 and receives payment 
instruments, certificates and private keys from the wallet manager 



422. 



The payment manager 430 also sends and receives transactions to the 
protocol manager 470 including a merchant's payment message 460, 
a consumer certificate and PK handle 450. a merchant URL 442, a 
payment 440, a signed receipt 434 and a GSO, Selected Payment 
25 Protocol and Selected Payment Instrument 432. The payment 

manager 430 also accepts input from the payment applet or MIME 
message from the merchant as shown at function block 480. One 
aspect of the payment processing is a Consumer Payments Class 
Library (CPCL) 470 which encapsulates the payment protocols into a 
single API. By encapsulating the payment protocols, applications are 
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insulated from protocol variations. A SETT Protocol provides an 
implementation of the client-side component of the Secure Electronic 
Transaction (SET) Protocol. A complete implementation of the client- 
side component of the CyberCash micro-payment protocol is also 
5 provided. 



The Wallet Manager 422 provides a standard interface to the wallet. It 
defines the wallet database structures and the payment instrument 
data structures, controls the access to the wallet and provides 
concurrency checking if more than one application attempts to open 
the same wallet. The interface to the wallet manager 422 is published 
to allow OEMs to interface with the wallet manager and access the 
wallet database. 



10 



15 



The waUet manager consists of the following sub-components: 
Wallet Access. This component provides an interface to read and 
write wallet information. 

Transaction Manager. This component provides an interface to read 
and write transaction corresponding to a wallet into the wallet 
20 database. 

Payment Instrument Manager. This component manager provides a 
common interface to the specific payment instrument access 
components. 

Credit Card Access, Debit Card Access, Check Access. These 
25 components deal with a specific payment instrument. 

A Data Manager provides storage and retrieval of generic data items 
and database records. It is assumed that data fields, index fields or 
entire data records can be marked as encrypted and the encryption 
30 process is largely automated. The data manager has no specific 
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knowledge of database records appropriate to different payment 
methods. This layer is separated out so as to reduce changes required 
when new payment methods are introduced. However RSA key pairs 
and certificates might be considered as "simple" data types. This 
component also provides an abstraction which supports wallet files on 
computer disk or contained in smart cards. 

The Open Data Base Connectivity (ODBQ/Java Data Base 
Connectivity (JDBC) component provides Data Base Connectivity 
where formal database components are required. An embodiment of 
the Smart Card Wallet allows wallet data to be stored and/or secured 
by a cryptographic token. 



A preferred embodiment includes a single file or directory of files 
15 comprising a "wallet" which contains personal information and 
information about multiple payment methods with the preferred 
implementation. These payment methods ( Visa cards, debit cards, 
smart cards, micro-payments etc. ) also contain information such as 
account numbers, certificates, key pairs, expiration dates etc. The 
20 wallet is envisaged to also contain all the receipts and transaction 
records pertaining to every payment made using the wallet. A 
Cryptographic API component provides a standard interface for RSA 
and related cryptographic software or hardware. This support 
includes encryption, signature, and key generation. Choice of key 
25 exchange algorithm, symmetric encryption algorithm, and signature 
algorithm should all be configurable. A base class stipulates generic 
behavior, derived classes handle various semantic options (e.g. 
software based cryptography versus hardware based cryptography.) 
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The Cryptographic Software portion provides RSA and DES support. 
This may be provided utilizing the SUN, RSA or Microsoft system 
components depending on the implementation selected for a 
particular customer. Cryptographic Hardware creates a lower level 
API which can underpin the Cryptography API and be utilized to 
replace Cryptography Software with an off the shelf cryptography 
engine. 

The message sequence charts describe the flow of messages/data 
between the consumer, the browser and/or the various major 
components of the Semeru system. The major components of the 
system are the Merchant system which includes the vPOS, the 
PayWindow, and the Payment Gateway. The merchant system allows 
a consumer to shop, accept the payment transactions sent by the 
1 5 PayWindow application, and send payment transactions to the 
acquiring bank. The Consumer Payments Class Library (CPCL) 
module is a layer within the application which sends the payment 
transactions, securely, from the consumer to the merchant. 



25 



Figure S is a Consumer Payment Message Sequence Diagram in 
accordance with a preferred embodiment of the invention. The 
diagram presents the flow of messages between the consumer, the 
browser, the merchant system, the PayWindow application, and CPCL. 
This message flow describes the payment process from the time an 
order is completed and the consumer elects to pay. to the time the 
payment is approved and the receipt is returned to the consumer. 
The difference between the Native implementation and Java 
implementation of the PayWindow application is in the delivery of the 
order information to the PayWindow. Once the order information is 
30 received by the PayWindow, the flow of messages/data is the same for 
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both implementations. In the case of the Native implementation, the 
order information is delivered via a MIME message. This MIME 
message is sent to the PayWindow by the browser via a document file. 
In the Java implementation, the order information is delivered to the 
PayWindow by an applet. The merchant system sends an applet with 
the order information to the browser which in turn delivers the order 
to the PayWindow. Once the order is received, the PayWindow 
interacts with the consumer and the Protocol modules for the 
completion of the payment process. 
Enters Order a nd Clicks Calculate Order Ron 

This message represent the consumer order entry and the clicking of 
the 'Calculate Order' button. The consumer's shopping experience is 
all condensed into this one message flow for the purpose of 
highlighting the payment process. The actual implementation of the 
shopping process varies, however, the purpose does not, which is the 
creation of the order. 
Order 53Q 

This message represents the order information which is sent by the 
browser to the merchant via an HTML form. 

20 Payment Applet wi th GSO, PPPs , Als. merrhan, certificate and lipi. 
540 

On receipt of the order, the merchant system calculates the payment 
amount. This message represents the HTML page which is sent by the 
merchant system detailing the payment amount along with the Java 
25 payment applet which contains the GSO, PPPs, Als. merchant 
certificate and URL. 
Run Payment Applet 545 

The Java enabled browser runs the Payment applet. The applet 
displays a button called "Pay" for the consumer to click. This is 
30 embedded in the HTML page delivered by the merchant: 
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Clicks Pay 550 

This message represents the clicking of the Pay button on the browser 
by the consumer after confirming the payment amount. 
GSO, PPPs. Ms. mercha nt certificate and URL Kfin 
5 This message represents the GSO, PPPs, AIs, merchant certificate and 
the merchant URL carried by the Java applet. The Java applet now 
delivers these to the PayWindow application. 



10 



Merchant certificate 562 

This message represents the merchant's certificate which is sent to 
the CPCL module for checking the validity of the merchant. 
Merchant's validity 564 

The CPCL modules examines the merchant's certificate and send this 
message to the PayWindow indicating whether or not the merchant is 
1 5 a valid merchant. 

Wallet. Payment Instruments 566 

This message represents the wallets and payment instruments that is 
displayed to the consumer. Not all payment instruments from a wallet 
is shown to the consumer. Only the ones accepted by the merchant is 
20 shown. 

Payment Instrument 568 

This message represents the payment instrument selected by the 
consumer. This message is created in the current design when the 
user double clicks on the payment image in the "Select Payment 
25 Method" Window. 
GSO 570 

This indicates that the GSO is displayed to the consumer in the 
"Make Payment Authorization" screen. 

30 Authorization of Payment 572 
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This message represents the authorization of the payment by the 
consumer. The consumer authorizes the payment by clicking the 
'Accept 1 button on the "Payment Authorization" screen. 
Decide Payment Protocol 574 
5 Once the consumer authorizes the payment, the payment protocol is 
decided by PayWindow based on the merchant's Payment Protocol 
Preferences and the consumer selected payment instrument. 
Payment Authorization 575 

These messages represent the merchant's URL, the GSO, payment 
protocol (PP) to use, account number, certificate and the private key 
handle (PK) associated with the payment instrument which is sent to 
the protocol module. 
GSO with Pa yment Authorization 576 

This message represents the payment instructions which is sent by 
the protocol module to the Merchant system. The GSO, PI, consumer 
certificate and PK is packaged based on the payment protocol. 
Signed Receipt 578 

This message represents the digitally signed transaction receipt 
received by the protocol module from the merchant. 
Save Receipt with hash value 58Q 
The digitally signed transaction receipt is saved by the PayWindow for 
future reference. 
Payment Successful 582 

This indicates that the transaction receipt and the 'payment 
25 successful' have been displayed to the consumer. 

PayWindow Requirements in Accordance 
With a Preferred Embodiment 

There are various requirements that a consumer demands of a 
30 paywihdow application, such as, support for a particular target 
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hardware platform, secure communication of payment information on 
the public network, easy configuration and accessibility, simplified 
order entry and transaction completion, store payment instrument 
information safely and securely, provide a wide variety of payment 
5 instruments, retain URLs of consumer's favorite shops, launch 
browser from the payment window to visit shops, keep records and 
export records for transaction data, provide shopping assistance, 
support multiple users with a single application, display merchant 
certificate and payment forms that are acceptable to a particular 
merchant, manage digital credentials, provide multiple accounts for a 
single payment type, provide support for merchant value add or 
loyalty programs and the support must be portable to another client 
machine. 



10 



15 A merchant has a different set of requirements for a payment 

application which include: consistent information format; loyalty and 
branding opportunities; multiple payment types for a consumer to 
select from; tight integration with a merchant store; links from the 
system to the merchant's store, better risk management / rates 

20 utilizing the system. A link could be a hypertext connetion between 
two displays, a point-to-point connection between areas in a single 
display, a Uniform Resource Locator (URL), an index, a reference to an 
address or other means which facilitates transfer of control from one 
area of execution to another area of execution (across machines, 

25 network locations or even satellite linkages and microwave 
transmissions). 

A preferred embodiment in accordance with the invention provides a 
software application used by the consumer to make electronic 
30 payments. It runs on the consumer's workstation and is either a free 
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standing application to a WWW browser or is embedded into a custom 
application, and is invoked whenever the consumer has completed the 
ordering process for a particular item and is ready to pay. 

5 The Pay Window application in accordance with a preferred 
embodiment supports multiple local users. Each user's data is 
independently stored and secured. On program startup, a user must 
sign in with an ID and password. All information (on local disk or 
floppy) is encrypted with a password entered by the user each time the 
10 program is invoked. 

Payment Instruments 

Due to the varying size of transactions and differing payment 

instrument usage related to social, economic and cultural factors. 

support is required for multiple payment instruments. Much like 
15 today, a consumer making a purchase from a merchant must have a 

choice of payment methods depending upon their personal preference. 

The supported payment instruments include: credit cards, electronic 

checks, electronic money, micropayment (electronic coin), debit card 

and smart cards. 
20 Secure Payment Protocol 

One of the core features in accordance with a preferred embodiment is 
the ability to accept and make payments in a secure and reliable 
manner. Secure payment on the Internet becomes as safe and reliable 
as Point of Sale (POS) terminals today with payment solutions in 
25 accordance with another aspect of the present invention. While 

selection of a security protocol can be considered a technical design 
consideration, there is high marketing value in supplying quick time 
to market in the solution. 

Payment Process 
30 The payment process is separated from the administrative function. 
Once a consumer has decided to make a purchase from the merchant. 
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the application requests a user name and wallet password, display 
merchant and order information, request that a user select a payment 
instrument from the wallet, and display and capture order 
acknowledgement and digital reciept. Basically for a payment 
instrument you can utilize any instrument that is evidence of 
membership, identity, certification or authority. For example, a card 
for video membership could be utilized to check out videos 
electronically via the internet. 
Transactions Supported 
The application in accordance with a preferred embodiment is able to 
originate sales and refund transactions types. It also provides 
automatic fill-in of addresses based on a user preferences file, and if 
no information is specified when a transaction is initiated, the 
information from the last payment transaction is utilized as default 
1 5 information. 

Shopping Support (shopping companion) 
The application in accordance with a preferred embodiment also 
shares payment and shipping information with the merchant and 
URLs from merchants which a consumer has frequented before 
20 linkage for visitation. 

Administrative Functions 

To simplify use of the application, actual payment and administrative 
functions are separated. Users are not presented with administration 
information while trying to complete an on-line payment process. 
25 Therefore the following administrative functions are supported: 

Data Management 

Data is automatically backed up to disk on a periodic basis based on 
user requirements. A user can view the contents of a backup in 
30 various ways. For example, a user can restore selected data from a 
backup, everything stored, selected user information only, or 
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everything except payment history information. Data export is also 
supported for selected digital receipts or order acknowledgements for 
email or to print for dispute resolution with a bank or other merchant. 
Data export is also provided to the following financial programs: 
Quicken, Microsoft Money and Managing your money. 
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Receipt and Transaction History Management 

Receipt and transaction history management is also provided for 
viewing order history by time, payment instrument type, merchant 
and by completed, uncompleted or pending transaction. A purge 
order history transaction is also provided to purge the order history 
file by time or by payment instrument type. Another report is 
provided which shows digital receipts for orders placed including 
credit card number, expiration date, name, billing address and public 
key certificate. Order acknowledgements are also transmitted for 
every order that has been placed, and an export status tag is 
generated if an item has been exported to an external financial 
management program. 

User Administration 

Various user administration transactions are also provided. They 
include a feature that creates an empty wallet for an user and sets a 
default password for the user when a new user is created. A delete 
user, change user password, and sign on as a user is also provided, 
but requires a user's password to activate. A view list of users is also 
provided and does not require a password to see the users defined to 
the system. 

Wallet administration 

Wallets are user specific and require the particular user to whom the 
wallet belongs to be effective. A preferred embodiment provides 
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transactions for adding a new payment instrument, deleting a 
payment instrument, viewing a list of payment instruments and 
modifying a payment instrument. 



10 



Loyalty Programs and Coupons 

Coupons are also accepted as well as other loyalty programs that a 
merchant might utilize, and provisions are provided for viewing loyalty 
program status and viewing existing coupons. 
Interoperability 

A preferred embodiment of the invention interoperates with many 
browsers and merchant systems. The requirements for 
interoperability across browsers and merchants applies to a base level 
functionality. 
Smart Card Integration 
1 5 Smartcard integration provides the consumer another payment 

method (stored value on a smartcard), portability of wallet information 
(key, payment instrument info, etc.). 
International Localization Requirements 
Support for localization to a particular country is built into the 
20 product for the major countries of the world. 

Figure 6 is a flowchart setting forth the detailed logic of a paywindow 
user interface in accordance with a preferred embodiment of the 
invention. Processing commences at function block 600 where an 
internet browser implemented as a Java applet detects the selection of 
25 a payment button and a test is performed at decision block 610 to 
determine if a wallet is open. If so, then the method of payment is 
determined at function block 630 and if a user cancels the processing, 
then control is returned to the Internet Browser at 632. If a user 
selects payment authorization at function block 634, then if the user 
can cancel authorization as shown at function block 650, accept 
payment authorization as shown at function block 640, or change the 
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pay method as shown at 635 which results in a transfer of control to 
function block 630. If the wallet was not open when the test was 
performed at decision block 610, then the wallet is opened as shown 
at function block 620, and control is passed to the Administration 
Screen at 622 for processing consistent with the logic presented in 
Figure 7, or if the user cancels processing, then control is returned to 
the Internet Browser as shown at 624. 

Figure 7 is a flowchart of the detailed logic associated with the 
administration mode of the paywindow in accordance with a preferred 
embodiment. Processing commences at function block 700 when the 
application is desktop launched. A user is first exposed to the 
PayWindow 710 which has a number of selections available. If a user 
selects a wallet 720 then at function block 721. the wallet is opened 
and control is passed to function block 722 for a particular form of 
payment to be selected. Once the particular form of payment is 
selected at 724 or payment selection is cancelled at 726. then control 
is returned to the main paywindow at function block 710. However, if 
a user has selected to open a new wallet at function block 721. then 
20 control is passed to the administration function block 740 for further 
processing. 

If a user selects administration mode from the main paywindow 710, 
then another test is performed at decision block 732 to determine if 
the wallet is open. If the wallet is open, then control is passed to the 
administration function block 740 for further processing. If a user 
selects reg,ster processing 712 from the main paywindow 710, then 
control is passed to the register function block detailed in Figure 8 at 
800. If a user selects reports processing, then control is passed to the 
reports function block 860 of Figure 8 for further processing. If a 
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user selects backup / restore 716 then a backup or restore is 
performed utilizing the operating system tools in accordance with a 
preferred embodiment as described above. 

5 If the wallet is determined to not be open at decision block 732. then 
control is passed to function block 734 to open the wallet. After the 
wallet is open, then control is either passed to function block 736 to 
select payment, or if the user has cancelled the operation, control is 
passed to the main window 710 or if this is a new wallet, then control 
10 is passed to the administration function block 740. 

When control passes to the administration function block, then if the 
wallet tab is selected, then control passes to the administration wallet 
page at function block 750 and if a user is interested in browsing. 
15 then a file open dialog is initiated at function block 760. or if a 
request to remove the wallet from processing is received, then a 
remove confirmation dialog is initiated at function block 770. If a 
user is interested in changing the administration preferences, then 
control is passed to function block 780. If a payment administration 
20 processing is selected, then control is passed to the administration 
payment page as shown in function block 790 where a certificate can 
be installed as shown in function block 796. a confirmation dialog can 
be added at function block 794 or a remove confirmation dialog is 
processed at function block 792. When administration processing is 
25 completed, control is passed back to the main paywindow at function 
block 710. 

Figure 8 is a flowchart of administration mode process.ng associated 
with register and report processing in accordance with a preferred 
30 embodiment. Processing commences at 800 where control is passed if 
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an administrative register task is to be processed. The register 
function is parsed at function block 802 and if a detail function is to 
be processed, control is passed to function block 850 to determine if a 
hot link to a merchant site is desired. If so, then control is passed via 
5 852 to launch a browser and go to the merchant site at 856. If not. 
then control is passed via 858 back to the register function 802. If a 
find function is to be processed, then control is passed to function 
block 840 where a find operation is performed for a particular item 
844 or a find next operation is performed 842. When find processing 
0 is completed or cancelled 846. control is passed back to the main 
register screen. If a customize register processing is desired, then 
control is passed to function block 830 to customize the register. If a 
clear operation is required, then control is passed to 832 to clear the 
register. When the customize operation is complete, then control is 
5 passed back to the main register processing. If a delete register 
operation is requested, then control is passed to function block 820 
and a delete confirmation dialog is conducted at function block 822. 
Finally, if an output register operation is requested, then the register 
window is removed at 804. control is passed to function block 810 
) and a file open dialog is initiated at function block 812. When the 
dialog is completed, then control is returned to function block 802. 

If a report button is pressed from the administration paywindow 
screen, then control is passed 860 to the reports function block 870 
to customize reports at function block 880. clear reports 882 or 
output reports 872 which is accomplished via a file open dialog at 
function block 874. 
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Figure 9 is an illustration of a paywindow display in accordance with 
a preferred embodiment The paywindow display 980 presents a list 
of available payment instrument holders in graphic form such as a 
purse bit image 900. or wallet bit image 910, 920 to a user once an 
5 appropriate password is entered via an entry point 930. A scroll bar 
922 is provided to allow the list of available payment methods to be 
scrolled, or selecting the up arrow 924 or the down arrow 926 can be 
used to review the available payment methods. In addition, there are 
areas provided at the bottom of the screen for opening 970, creating a 
new 960 wallet and cancelling 9S0 payment. The Cancel button 9SO 
invokes the display of the payment cancellation screen. Finally, a 
message area is provided at the bottom of the screen for 
communicating system messages 940. If a user presses the right or 
left mouse button the focus of the window is shifted accordingly. The 
1 5 tab key on the keyboard attached to the cpu is utilized to move and 
cycle the highlight between various controls on the display. If the 
enter key is pressed, the highlighted control is activated. For example, 
if the enter key is pressed after information is entered into the 
password field 930. then the password is checked with the password 
file to determine if a valid password has been entered. The wallet's 
listbox is a single selection listbox which displays all the wallets 
installed on the system. A user may utilize the mouse or keyboard to 
select a wallet to open. The New button 960 creates a new wallet file 
and displays the 'Administration' dialog for wallet information entry. 
25 Payment Instrument 

Figure 10 illustrates a list of payment instruments represented as bit 
mapped images for a user to select from in accordance with a 
preferred embodiment. The payment instruments include a credit 
card, debit card, smart card, ecash, micropayments and electronic 
checks. The open button 970 invokes the payment instrument 
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«— . flr cl,c k .„ e „„ ^ bulWn 1000 comroi js u 
an au.honza.ion screen „her. the detai,s of .he ^ displayed 
The payment instruments represented in Figure 10 includ(; , Ban|< 
America* Vis, X04O „ith . image ^ „ 

I" S ^ C " d ' 80 S " Ch **™~" - ~ instrument 
ho d„ name, instrument name, membership period and expiration 
dale. Such .mages can be obtained by scanning the user's cards or 
utilizing the manufacturer's .emplate and adding represent of 

the user's name. 

A Chevron checking account 1020 is a.so prided with an enlarged 
Chevron logo to represent the user's checking account which is 
another type of payment instrument that is supported in a preferred 
embodiment. A Wells Fargo Visa 1030 payment instrument is also 
prodded in accordance with a preferred embodiment. Whereas 
realistic representations of actual visa cards are represented in F igurc 
lO. one of ordinary ski,, in the art wi„ readily aporecate that other 
user-defined graphic or text information can be utilized to represent 
the payment instruments. Pressing the Cancel button 1010 goes 
back to the Payment Cancellation screen. Choosing Bob's wa„et 1050 
goes back to the open wallet display screen to enter Bob's wallet 
password 930. Double clicking on any payment instrument takes you 
to an authorization screen for that particular payment instrument 
Chckmg on a payment instrument icon puts a border around it 
indicating it has been selected. An example of the border is shown for 
Jane's purse 1060 and the graphic associated with Jane's purse has 
an md.c.a of the open state which is a graphic in an open position as 
shown at 1060. Similarly, if . wallet is seIected ^ ^ ^ ^ 
1050, the graphic associated with the wallet could be represented 
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portrays an open wallet. 

Source code in accordance with a preferred embodiment is provided 
below as another form of detailed logic disclosure. The 
WalletBrowserPanel class displays the wallets and the payment 
instruments contained in it. It utilizes the PasswordEntryPanel, 
ImageSelectorPanel and the Imageltem classes. The 
PasswordEntryPanel class accepts the password for a given wallet 
from the user. The ImageSelectorPanel class displays the wallet icons 
and the payment instrument icons and allows the user to 
select/deselect an wallet or instrument. Displaying of an icon on the 
screen is managed by the Imageltem class. 



10 



15 



20 



25 



30 



35 



40 



45 



import j ava . awt . « ; 
import java.net.*; 
import java.util. «; 

public class WalletBrowserPanel extends Panel ( 
private Paywindow payWindow; 
private WalletManager walletManager- 

private ImageSelectorPanel walletPanel. instrumentPanel • 
private Button btnOK, btnCancel; ' 
private Panel buttonPanel. walletDetail • 
private PasswordEntryPanel PasswordEntryPanel ; 

private Insets insets . new insetsUS. 15, 15 15. - 
private ImageltemRef openWalletlmageltem = null; ' 

public WalletBrowserPanel (Paywindow pw) { 

paywindow = pw; 

H^v tManager " WalletMana ^r.ge t Walle tM anager(J; 
btnOK « new Button ( "Open- J ; 

btnCancel = new Button ( -Cancel ") ; 
buttonPanel - new Panel () ; 
IS, 10),; bUtt ° nPanel - aetLa ^t<new FlowLayout (FlowLayout . CENTER, 

buttonPanel . add (btnOK) ; 
buttonPanel. add (btnCancel) - 

xnstrumentPanel . new ImageSelectorPanel (false, null)- 
walletPanel = hew ImageSelectorPanel ( false , null). 
Enumeration walletNampq - ^=,n«*- M -* ' 
String name.- iletName3 " wall ^Manager .getwaliecNames ( 1 , 

Wallet wallet; 
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w hile(walletNames.hasMoreElementsO) { 

name * <String) walletNames .nextElement () ; 

wallet * walletManager.getWallet<name>; 
5 try { 

walletPanel. addlmage (name, new 

URL(walletManager.getItnageDir () + 

wallet.getCloseBitmapO), wallet)- 
) catch (Exception e> { 

jq Sys teen. out. print In (e ) ; 

} 

passwordEntryPanel = new Pas ewordEntry Panel (this) - 

wtl^^^^ ryPanel ' fietPanelS " e(n ^ ^nsion(37 5 ; 290), 
walletDetail = new Panel (); " 

walletDetail . setLayout (new'cardLayout () ) • 

walletDetail . add < "PasswordEntryPanel « 

passwordEntryPanel) ; 

walletDetail. add (-instrumentselection^ instrumentPanel) 
setLayout (new BorderLayout () ) ; J 
add ( -South- , buttonPanel ) ; 
add(-West-, walletPanel); 
add ("Center-, walletDetail); 

walletNames - walletManager igetWalletNames () ; 
name = (String) walletKames .nextElement () ; 
passwordEntryPanel . setWallet (name) - 
^ displayopenwallet () ; 

public void openNewWallet () { 
o ft ImageltemRef imageltemRef = walletPanel. 

JU /f getSelectedltemO ; 



passwordEntryPanel . setWallet (imageltemRef .getName ( , > 



// 

// btnOK.se t Label (-Open") - 

U ((CardLayout) walletDetail. getLayout(J) 



- : 3 *»«**/vu c \ / j . 

-.c y. show (walletDetail, -PasswordEntryPanel") - 

JJ U PayWindow.setTitle(-PayWindow . Open Wallet-)-' 

displayOpenWalletO ; 

} 

public void getPaytnentlnstrument ( , { 
Acs ImageltemRef imageltemRef » walletPanel. 

HU getSelectedltemO ; 

Wallet openwallet = pay Window. getOpenWallet () ; 
Wallet selectedWallet « 
(Wallet) imageltemRef .getUserObjectO ; 
45 if < ( sel ectedWallet !«null) (openwallet !« null) tt 

openwallet. equals (selectedWallet)) { 
n btnOK. setLabel ("Select") ; 

( (CardLayout) walletDetail. getLayout (> ) . 

show<walletDetail, "InstrumentSelection-) ; 

50 Method-); P»yWindow.setTitle(-PayHindow - Choose Payment 

^ displayChoosePaymentMethod(, ; 

else { 

JJ displayOpenWalletO ; 
\ 



// 
// 
// 
// 
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} 

public void disableOpenButton ( ) { 
btnOK. disable () ; 

} 

5 public void enableOpenButton () ( 

btnOK. enable () ; 

} 

public void newWal let (Wallet wallet) { 

System. out. println ("Wallet Browser - newWallet") ; 
10 try { 

walletPanel .addlmage (wallet .get Name () , 

new URMwalletManager.getlmageDir () + 
wallet .getclosefiitmap () ) , 

wallet) ; 

15 } catch (Exception e) { 

Sys tern. out. print In (e) ; 

} 

) 

public Insets insets () { 

20 

return insets; 

} 

public boolean handle Event (Event evt) { 

25 if (evt. target «= instrument Panel) { 

if (evt. id -« 
ImageSelectorPanel . EVENT_IMAGEDOOBLECL I CK) { 

Payment Instrument instrument; 
30 ImageltemRef imageltemRef = 



< ImageltemRef ) evt .a rg; 



instrument = ( Payment Instrument ) 

imageltemRef . getUserObject () ; 
payWindow. authorize Payment (instrument) ; 



35 } 
J 

else 

if (evt. target «*- wallet Panel) { 

40 if (evt. id *« 

ImageSelectorPanel .EVENT_ IMAGE SELECT I ON) { 

ImageltemRef imageltemRef = 

(ImageltemRef) evt .arg; 
45 wallet wallet - 

(Wallet) imageltemRef .getUserObject () ; 

if (wallet == pay Window. getOpenWal let () 
payWindow . is Payment Request ( ) ) { 
// btnOK.setLabel ("Select") ; 

50 // ( (CardLayout) wa lie tDe tail .getLayoutO ) . 

// show(walletDetail. 
■ Instrument Select ion") ; 

// payWindow. se tTi t le ( "PayWindow - Choose 

Payment 

55 Method 1 *) ; 

d ispl a yChoose Payment Me chod ( ) ; 
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u Passwor ^tr yPa „el. S e t Hane t ,i»a 3e r t en, R e £ . g e t Na m e(„. 

// b tnOK.eetLabel<-Open-J • 

•PasswordEntryPanel-J . "ecoetail. 
// 



15 



10 iillef) ; payWindow - fietTi tle("PayWindow-Open 

displayOpenWallet () ; 

) 

} 

else 

if (evt. target btnOK) { 

if (evt. id « Event. ACTION_EVENT> ( 

if (btnOK.getLabel() « -Open") { 
20 S y stetn out.printlnCOpen-) - 

ImageltemRef xmageltem « walletPanel 

getSelectedItem(J ; 
Wallet selectedWallet = 

25 (Wallet >in«geItem.getU3erObject(J ; 

// validate the password 
// close any open other open wallet 
if (openWallet Image Item •« null) { 
30 Wallet prevOpenWallet = (Wallet) 

openWalletlmageltem.getUserObject () ; 

prevopenwaller. close () 

35 try { 

walletPanel. changelmage ( openWallet I mage Item, 

URUwalletManager.getlmageDirO + nCW 

prevOpenWallet.getCloseBitmapO ) ) ; 

} catch (Exception e) { 

System. out. println(e) ; 



40 



} 

45 > 

// open selected wallet 

«aUe t Manager.ope„KaHe t ,selec t edWall et . gecNanien . 

5Q payWindowset OpenMallet( 3 electedWallet) ; 

openwanecimageiten, = image It em; 
// display open wallet icon 
cry { 

5s waUetPa "elchangeImag e (i ma g eItem , 
URLIwalletManager.getlmageDirO ♦ 



14:47:04 



WO 97/4 1537 PCT/US97/06939 

-51- 

selectedWallet .getOpenBitmap 0 ) ) ; 

} catch (Exception e) { 

System. out .print In (e) ; 

5 I 

// get instruments 

instrument Panel . retnoveAl 1 Elements () ; 
Enumeration instrument Names B 

10 selectedWallet.getlnstrumentsO 

Payment Instrument instruments- 
String name; 
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while (instrumentNames.hasMoreElements <) ) { 

name = 

(String) instrumentNames.nextElement () ; 

instrument = 

selectedHallet .get Instrument (name) ; 

try { 

instrument Panel . addlmage (name , 

r 

URL(walletManager.getlmageDir () + 



25 instrument .getBitmap () ) , instrument) ; 

) catch (Exception e) { 

System. out. print In (e) ; 

} 

} 

if {payWindow. is Payment Re quest () ) { 
// display instruments 
// btnOK. setLabel ( "Select") ; 

// 

( (CardLayout)wal letDe tail, get Layout () ) . 
35 // showtwalletDetail , 

-InstrumentSelection" ) ; 

displayChoosePaymentMethodO ; 



^ else { 

payWindow . showMenu ( > ; 
} 

) 

else 

if <b tnOK. get Label () *== -Select") { 
4$ Payment Instrument instrument; 

ImageltemRef imageltemRef = 
instrumentPanel . getSelectedltem ( ) ; 

instrument = (Payment Instrument) 

imageltemRef .getUserObject () ; 
*>V payWindow. authorize Payment < instrument ) 

} 

I 

} 

else 

55 if (evt. target «« btnCancel) { 
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} 



it <PayWindow.i SPaynientR 
else { 

paywindow . ehowMenu ( ) ; 

} 

return super. handleEvent (evt) ; 
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public void paint (Graphics g) 

SdravLine (insets. left. sizeO held,- • 

sizeO uIHi-k • n «iSTht- insets, bottom, 

insets. bottom); ° Wldth - lns ets. right. sizeO. heigh™ 

9.drawLine< insets. left. si2e() hel „ K( . . 

sizeO uihm. ' " ze " • nei ffht-inseta.bottom+i 
insets. bottoms); ° Wldth -« S ets . right, size () .height 

private void dis P layOpenWallet() { 

=S^r iet '^r te^ef .getHa-ne ( , , , 
25 ' ^^"^alletDetail .getLayoutO ) . 

btnOK. enable () ; 

( (CardLayout . walletDetail .getLayout ( ) ) 
snow wailetDpt-aii « t 

} 1C( Pa y"^dow - choose Payment Method-); 
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class PasswordEntryPanel extends Panel { 
private Image panellmage- 
private Text Field password; 

// private URL imageFileURL*; 

private Dimension panelsize; 



paneisize; 

private Label enterPasswordLabel - 
private Label walletNameLabel • ' 
private WalletBrowserPan^l U3 ii *.r> 

puttie , 

walletBrowserPanel = w bp- 

50 S^iT^Lr — d er (Chis) ; 

try { WalletMana 9er.getWalletManag e r() 

/ / 



^ it*ageFileURL = new 



55 p:^::;; /e:/htdocs/p *^^ 
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URL ( "http : //kimberly/PayWindow/JavaDemoDev/ images/open .wallet . backgro 
und.gif " ) ; 

} catch (Exception e) 

System. out .println(e) ; 
5 // panellmage « imageLoader .Loadlmage (image Fx leURL) ; 

panellmage - imageLoader .Loadlmage (wm. get PwdScr Image ()) ; 
panelSize = new Dimension (panellmage .getWidth( this) , 

panel Image. getHeight (this) ) ; 
enterPasswordLabel » new Label (-Enter the Password for" 
10 Label. CENTER) ; * 

walletNameLabel * new LabeK*-, Label .CENTER) ; 
password « new TextFieldO; 
password . setEchoCharacter (•*•); 
set Layout (null) ; 
15 add ( pas sword ) ; 

add (enterPasswordLabel) ; 
add (walletNameLabel ) ; 

} 

public void setwallet (String walletName) { 

walletNameLabel. setText (walletName*- : "> ; 
pas sword . setText ("•■); 
^ walletBrowser Panel. disableOpenBut ton () ; 

public void set PanelSize (Dimension size) { 
25 panelSize « size; 

) 

public String getPassword () { 

return password. getText () - 

) 

30 

public Dimension minimumSize ( ) { 
return pref erredSize () ; 
35 public Dimension pref erredSize () { 

return panelSize; 

} 

public boolean handleE vent (Event evt) { 
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if (evt. target «= password) { 

if (evt. id Event. KEYRELEASE) { 

if (password.getText () .length () 0) { 

^ walletBrowserPanel .disableOpenBut ton () 

else { 

walletBrowserPanel . enableOpenBut ton ( ) ; 

} 

} 

return super .handleEvent (evt) ; 

} 

public void update (Graphics g) { 
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^ paint (g) ; 

public void paint (Graphics 9) { 

5 S ^e«,. hei3h ^ d c r *L 1 r e<PaneUBa9e ' °' °' •*»«»■•««.. 

g.drawlmage (panel Image, 

SSI! '2St ' pMMll "-9«-s««-th(thisi 1 /a . 
10 thxa); 9 " ^ nelI ™9 e -S«Hei 9 h t (thi s >,; 2 . 

int labelHldth; 

£ ! atMetriCS ■ 9-^FontMetricsO; 
labelWidth - fontMetrico.stringWidthC 

labelWidth- fontMetrico.strin 9 Width( 
^ w »lletNameLabel.getTextO| ♦ 60- 

100, 20); 

25 g.drawRect(0. o. eizeO .width- 1. eizeO .height-1, • 

} 
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Authorization 

Figure 11 is an authorization display screen in accordance with a 
preferred embodiment. The authorization screen displays the 
transaction details and facilitates a user's examination of all the 
details of a particular transaction. It also allows a user to accept or 
cancel a transaction, or change the payment method for a particular 
transaction. The payment button on a web page launches this screen 
when a wallet is already open. The change payment method 1 100 
d.splays the Payment Instrument screen to allow a user to choose a 
different payment instrument and transfers control to the paywindow 
d.splay shown in Figure 9. The Order tab 1110 controls the display of 
pages of information about the transaction on order, merchant or 
address. Pressing the accept button 1140 signals the user's 
acceptance of the transaction, and it records the transaction data into 
the wallet's register and displays a PAID receipt as shown at 1200 at 
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Figure 12. Pressing the Cancel button 1160 displays the payment 
cancellation screen as shown in Figure 13 at 1300. 
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PayWindow Main 

Figure 14 illustrates a Main screen in accordance with a preferred 
embodiment of the invention. This screen is displayed when a user 
runs an application in the local mode and indicates that the 
paywindow is operating in administration mode. The application 
launches from the desktop. The screen controls include a button for 
selecting wallet 1401 which displays the paywindow screen and 
allows a user to open or create a new wallet. Another button the 
report button 1410 opens an instance of the report window when it is 
selected. Selecting the register button 1420 opens the register 
window which allows a user to select from a variety of register 
transactions. Selection of the administration button 1430 opens the 
administration screen which allows a user to perform various 
administrative tasks. If a user selects the backup/ restore button 
1450, then the backup/ restore dialog is initiated. Finally, selection of 
the exit button 1460 closes the screen and terminates the application. 

Administration 

Figure IS is an illustration of an Administration d.splay screen in 
accordance with a preferred embodiment. This is the main screen for 
entenng information pertinent to wallets, payment methods and user 
preference settings into the system. The information is organized and 
presented in pages of grouped data. The Administration display is 
launched from the Administration button 1430 of F,gure 14 in 
response to selection of the button by a user. The wallet tab 1510 
controls management of pages of related information pertaining to the 
currently active waUet. Users can utilize the mouse or the keyboard to 
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modify the pages of information. The done button 1590 saves the new 
information in the wallet when it is selected. The cancel button 159 5 
discards the changes and closes the display screen when it is selected. 

Figure 16 illustrates a display of the administration wallet page in 
accordance with a preferred embodiment. The user must enter the 
name of the wallet into the entry field 1660, the wallet's owner must 
be entered at 1670, a password corresponding to the named wallet 
must be entered at 167S the password entry is displayed with — 
characters entered in place of the letters and numbers of the 
password, and a confirm password must be entered at entry field 
1678. This confirm password 1678 must match the password 
entered at 1675. The browse button 1680 opens the file open dialog 
to present a user with a list of wallets to choose from using a wallet 
15 icon file as input to the process. The remove wallet button 1685 
removes the current wallet from the system and displays a 
confirmation message box prior to deletion. 



30 



The administration payment tab 1520 of Figure 15 initiates a screen 
as illustrated in Figure 17. Figure 17 is a payment administration 
window in accordance with a preferred embodiment. A user may use 
payment page of the administration screen to view or edit a payment 
method's information. 

The listbox control 1710 displays all the payment methods currently 
installed in this wallet. A user can scroll the listbox control to see all 
of the payment methods available to the owner 1760. The user must 
select a payment method prior to viewing its information. The 
selection is accomplished by positioning the cursor over a payment 
method that the user requires and clicking the mouse button or 
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pressing the enter key to select that card as the method for payment. 
The card name edit field 1750 is used to display or edit the name 
that the system utilizes to refer to the currently selected method for 
payment. The card type data entry field 1760 corresponds to the 
various types of methods for payment. Many of the types are 
predefined for a user, such as: master card. visa, discover. 

An associated card number entry field 1780 is also provided to display 
and/or edit the card number. An entry field 1782 is also provided for 
display and/or edit of the card's expiration date. A certificate dialog 
box 1784 button is also provided for initiating the attachment or 
editing of a certificate. A checkbox control 1792 is also provided if a 
user desires to make the selected card the default method for payment 
for a particular wallet This is an attractive feature since it eliminates 
IS selection of a particular method of payment each time a wallet is 
opened. The ergonomics are well thought out to parallel a user's 
wallet in which the favorite credit card is usually stored in a 
convenient location for ready retrieval when the holder of payment 
methods (ie.. wallet, purse, briefcase, smart card) is selected. Two 
20 other buttons are provided for adding 1786 and removing 1790 a 
payment method to/from the holder of payment methods. The 
removal button 1790 displays a confirmation message prior to 
removal of the payment method. A button to signify completion of 
processing 1742 and a button for cancelling processing 1746 are also 
25 provided. 

Figure 18 is an illustration of the administration preferences page in 
accordance with a preferred embodiment. The address line one edit 
control 1810 is used to view or edit the first sh.pment address line for 
30 a particular user. The address line two edit control 1820 is used to 
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view or edit the second shipment address line for a particular user. 
The city edit control 1830 is used to edit or view the shipment city for 
a particular user. The state edit control 18S0 is used to edit or view 
the shipment state for a particular user. The zip code edit control 
1860 is used to edit or view the shipment zip for a particular user. 
The country edit control 1840 is used to edit or view the shipment 
country for a particular user. A button to signify completion of 
processing 1870 and a button for cancelling processing 1880 are also 
provided. 

Figure 19 illustrates the window controls in accordance with a 
preferred embodiment. The name of the active window is always 
displayed in the upper left hand corner 1930 for easy recognition by a 
user. The upper right hand comer has three buttons for minimizing 
the display 1900, maximizing the display 1910 and closing a display 
1920. One of ordinary skill in the art will readily comprehend that 
other windowing display tools could be substituted for the tools 
described without undue experimentation. A touch display screen 
could also be substituted for environments where a mouse or 
keyboard might not be appopriate. One could even envision the 
displays being manipulated using a remote control device (infrared) 
that interfaces with a television set for viewing, selecting and paying 
for purchases from the comfort of a living room or easy chair. 

25 Figure 20 is a register display in accordance with a preferred 
embodiment of the invention. The register display lists all 
transactions in chronological order and allows a user to navigate 
through and examiner transactions associated with a wallet. A user 
also has the option of searching for particular transactions and 

30 examining detailed transaction information for any transaction. 
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Finally a user can reconcile transactions against a bank statement as 
well as a shipment list of merchandise. This display is initiated by 
selecting the register button from the administration screen. A user 
may only create a single instance of the register display, so additional 
clicks of the mouse button is only be utilized to set the focus to the 
single register display window. Clicking on an item displayed on the 
register display sets the selection highlight to the hit record associated 
with the area the cursor is currently displayed. Double clicking brings 
up additional detail on the currently selected record. 



If the user presses the tab key, the cursor moves to and highlights the 
next control on the display. If the user presses the enter key, the 
highlighted button is invoked on the register display. When a 
transaction record is highlighted, pressing the up arrow key moves the 
15 highlight (selected item) to the preceding record. When a transaction 
record is highlighted, pressing the down arrow moves the highlight 
(selected area) to the next record. Selecting the home key sets the 
highlight to the first record in the register report, and similarly, 
pressing the end key sets the highlight to the last record in the 
register report. Selecting the detail button 2010 on the register 
display opens the register detail dialog. Selecting the find button 
2020 opens the register find dialog. Selecting the customize button 
2030 opens the register customize dialog. 



Once a user has customized a particular register, then the customize 
button 2030 displays a colored dot symbol to indicate an active filter 
is defined. If the delete button 2040 is selected, then the highlighted 
register is deleted after an appropriate confirmation message box is 
displayed and selected in the affirmative. Moreover, selection of the 
output button 2050. opens the output dialog with a user. Finally, 
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selectxon of the close button 2O60 closes the register screen. A scroll 
bar 2090 is also provided to allow a user to scroll through records 
extending over a single page. For each record, a date 2080, a time 
2082, a payment instrument 2084, an item 2086. an amount 2088 
» a paid 2070 and a received 2072 entry is provided in a columnar 
representation. The paid 2070 and received 2072 allow a user to 
check/reconcile a record when paying the credit card payment 

Figure 21 is register detail display in accordance with a preferred 
embodiment. The register detail display allows a user to view or 
examine all of the specific details of a transaction. The display is 
launched when a user double clicks on a highlighted transaction 
record, or when a user presses the detail 2030 button as illustrated in 
F,gure 20 of the register display. The order tab 2100 control selects 
an mformation page on the display. The Go To Merchant Site button 
2110 button spawns the internet browser and sets it to the merchant 
web page. The ShipToAddress 2120 provides a link to the address 
mformation for the selected merchant. The memo 2150 edit control is 
used to view/edit a short memo text for each transaction. The paid 
2170 checkbox allows a user to check/ reconcile a record when he or 
she pays the credit card payment. The received 2160 checkbox allows 
a user to check/reconcile the record when he/she receives the 
merchandise. The done 2140 closes the Register Detail' dialog and 
returns the focus to the register. 

Register Find 

Figure 22 is a register find display in accordance with a preferred 
embodiment. A user utilizes this display to search for a transaction 
record. The find button 2020 of the register display as described with 
reference to Figure 20 is used to initiate this display. The from date 
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220O control is used to enter the starting date of a transaction. The 
to date 2210 control is used to enter the ending date of the 
transaction. The combobox 2220 is used to list all of the payment 
methods in the wallet. A pulldown 2225 control causes a list of 
payment methods to be displayed to the user. The item 2230 control 
is used to enter a full or substring of the target item of the search. 
The merchant combo 2240 display lists all of the merchant names in 
the wallet. The item 2250 control causes a list of all the merchant 
names to be displayed for selection of the particular merchant name 
required. The memo 2265 edit control is used to enter the full or 
substring of the memo to search for. The cancel 2295 button cancels 
and closes the register find dialog. The find 2295 button starts the 
search command. The find dialog remains open during the search 
and the search result in the register is highlighted. The search up 
2260 button and down 2270 button direct the direction of the find 
operation. The find next 2280 button continues the search to locate 
the next register record. 
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Figure 23 is a register customize display in accordance with a 
preferred embodiment The display facilitates a dialog which allows a 
user to create a record filter for transaction records. It provides 
functionality to save, recall and remove filters. Saved filters are 
shared between the register and report functions of the paywindow in 
accordance with a preferred embodiment. To initiate this display, a 
user selects the customize button 2030 of the register screen. The 
from date 2340 entry field allows a user to enter a starting date to 
show the records after this date. The to date 2350 entry field allows a 
user to enter an ending date to show the records up to and including 
this date. The item 2360 entry field allows a user to enter a full or 
substring of the item field as a filter parameter. The received 2365 
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button allows a user to select a 'received' flag as a filter parameter 
The paid 2370 button allows a user to select a 'paid' flag as a filter 
parameter. The memo field 2380 allows a user to enter a full or 
substring of the memo field as a filter param eter. A user may select 
5 one or more payment methods as a filter parameter utilizing the paid 
by 2395 box. This multi-selection listbox displays all the payment 
methods in the wallet for a user to choose from. The merchant box 
2397 allows a user to select one or more merchants as a filter 
parameter. • This multisection listbox displays all of the merchant 
10 names in the transaction register for a user to select from. The filters 
2310 allow a user to name, store and retrieve filters by using the 
combobox and selecting, or entering a stored filter name The 
memorize 2320 button assigns the name appearing in the filter 2310 
box to the parameters specified on the display. The remove 2330 
15 button allows a user to select a filter using the combobox. and delete 
«L The clear 2385 button allows a user to clear all of the filter 
parameters. The ok 2390 button activates a filter and closes the 
customize dialog. The customize button of the register displays a dot 
indicating an active filter. 
20 Figure 24 is a register output display for directing the output target 
for register information. For example, a user may select a printer or a 
file as the target for outputting the results of a register display The 
output display is invoked by pressing the output button of a register 
d.splay. The user clicks the printer button 2400 to initiate output of 
25 reg,ster display information to the printer. A user selects the export 
button 2410 to output the register information to a file in a file format 
selected form the type 2420 combobox. The user specifies a 
path/name for the output file in text entry field 2430. A user may 
open the file save dialog by selecting the browse 2435 button and 
30 setting the output file path and file name. The cancel 2450 buton 
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cancels the operation and closes the dialog display. The ok 2460 
button closes the dialog and starts the output of the register screen. 

Report 

Figure 25 is a report of a wallet in accordance with a preferred 
embodiment. The display is a pre-formatted report for use in 
customizing a report. A user invokes the report by pressing a button 
of the paywindow display. The customize button 2500 opens the 
register customize dialog, If a colored dot appears inthe customize 
button 250O, then a filter is currently active. The output button 2510 
opens the output dialog. The done 2520 button closes the report 
window. The report type listbox 2530 allows a user to select a pre- 
formatted report type by using the report type combobox. The user 
can also select any of the fields 2540, 2550. 2560, 2570, 2580 or 
2590 to set the report sort field. The selected sort field appears as 
15 boldface in the sort field. 
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Report Customize 

Figure 26 illustrates a report customize display in accordance with a 
preferred embodiment. The screen allows a user to create a record 
filter for transaction records. It provides functionality to save, recall 
and remove filter(s). Saved filters are shared between the Register and 
Report functions of the PayWindow. To initiate this display, a user 
selects the customize button of the report screen. The from date 2692 
entry field allows a user to enter a starting date to show the records 
after this date. The to date 2694 entry field allows a user to enter an 
ending date to show the records up to and including this date. The 
item 2690 entry field allows a user to enter a full or substring of the 
item field as a filter parameter. The received 2684 button allows a 
user to select a 'received' flag as a filter parameter. The paid 2682 
button allows a user to select a 'paid' flag as a filter parameter. The 



14:47:04 



WO 97/41537 

PCT/US97/06939 



-64- 



memo field 2680 allows a user to enter a full or substring of the memo 
field as a filter parameter. A user may select one or more payment 
methods as a filter parameter utilizing the paid by 2630 box. This 
multi-selection listbox displays all the payment methods in the wallet 
5 for a user to choose from. The merchant box 2640 allows a user to 
select one or more merchants as a filter parameter. This 
multiselection listbox displays all of the merchant names in the report 
for a user to select from. The filters 2600 allow a user to name, store 
and retrieve filters by using the combobox and selecting, or entering a 
10 stored filter name. The memorize 2610 button assigns the name 
appearing in the filter 2610 box to the parameters specified on the 
display. The remove 2620 button allows a user to select a filter using 
the combobox. and delete it. The report header 2660 entry field 
allows a user to enter information for display as a title for the report. 
1 5 The clear 2670 button allows a user to clear all of the filter 

parameters. The ok 2650 button activates a filter and closes the 
customize dialog. The customize button of the report displays a dot 
indicating an active filter. 



20 



Report Output 

Figure 27 is a report output display in accordance with a preferred 
embodiment. A user can select the output target utilizing this dialog. 
This display is invoked by selecting the output button 2510 of the 
report display. A user may select a target of choice using this dialog. 
25 A user selects the printer 2710 checkbox if the ouput from the report 
is targettcd for a printer. This action disables all controls under the 
export button. A user selects the export button 2720 to output the 
report to an export file. This action enables all export button controls. 
A user selects a file format for the export operation file utilizing the 
pull down menu 2730. A user selects a path/file name for the output 
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file using the path data entry field 2740. The browse button 2750 
allows a user to open a file save dialog to browse and set the file path 
or file name. The cancel button 2770 cancels the operation and 
closes the dialog. The ok button 2760 closes the dialog and starts the 
output process. 



In an alternative embodiment fo the Register and Report functions 
described above, a separate financial application program, such as 
Quicken, could be utilized as a helper application with the internet 

10 program. This feature would have the additional advantage of 

allowing seamless reporting with other financial transactions bundled 
with the Quicken application. Another alternative embodiment could 
utilize JPEG format or GIF formatted files for storing and retrieving 
image files as a compression alternative. These standards are well 

1 5 known in the industry and proven effective for reducing the amount of 
storage that is necessary for saving graphic files and bit-mapped 
images. 



Payment Instrument Holders 

Figure 28 illustrates various payment instrument holders in 
accordance with a preferred embodiment. A moneyclip is shown at 
2800 and 2802. Various wallets are shown in the closed position at 
2810, 2814, 2830 and 2850; and in the open position at 2812, 
2816, 2840 and 2860. A purse in the closed position is depicted at 
2820 and in the open position at 2822. Finally, a smartcard is shown 
in the closed position at 2870 and in the open position at 2880. One 
of ordinary skill in the art will recognize that the depictions are 
representations of bit mapped images that could be stored as JPEG, 
GIF or other representations to conserve space. 
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Certificate Processing 
A payment instrument must ^ by ^ 

author before it M be used „„ . Mmputer ^ « 

bank,, but i, might als0 „ . merchant fcg SEARs) a 
aqmnng bank or an association such as VISA or Mastercard. 

Payment instrument information is stored i„ ^ consuIne , s 
The certificate which authors the payment instrument „„, * ' 
stored aiong with that data in a secured database. The prcess of 
acqumng a certificate is described below. A certificate can be 
dehvered to a consumer in a preconfigured waliet. The consumer 
reeves a walie, which contains the certificate together with the 
necessary detaiis associated with a payment instrument inCuding a 
payment instrument bitmap which is authorized by a certificate 
■ssuing authority or the agencies represented by the issuing authority. 

Obtaining a certificate 
A consumer will deliver or cause to be delivered information to a 
ceruficate issuing authority. Figure 29 is an illustration of a 
ccrfficate issuance form in accordance with a preferred embodiment 
A user may fill out the form on-Hne. on paper and mail ,t in. or get his 
bank or credit card company to deliver it. The consumer delivered 
data will usually contain a public key belonging to a security key pair 
generated by consumer software. This information wil, normally be 
maued to the consumer's address and actuated by a telephone call 
from the consumer. The certificate authority takes this informat.on 
and uses it to validate that he is indeed entitled to use the payment 
method. Th.s processing normally take, a few days to accomplish 
Information will normaHy be exchanged with the organization .ssu.ng 
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the payment method in the physical space if there is one, and with 
credit agencies. The certificate information is loaded into the 
consumer's software to enable payment processing to proceed online. 

In some cases the consumer will be able to select details about a 
payment instument holder (wallet) he desires to own. This may be the 
icon representing a holder, the access password or other information. 
After creating the certificate, the issuing authority can use information 
received in the certificate application to create a custom payment 
instrument holder ready to use. This payment instrument holder will 
contain the following information. Payment instrument information 
including card number 2900 and expiration date 2902. Personal 
information including name 2904, address 2906, social security 
number 2908 and date of birth 2910. 



The associated certificate ( eg X509 standard ), an associated public 
key or in some cases public/ private key pair ( eg RSA). and an 
approved bitmap representing the payment instrument are provided to 
the requesting consumer. Figure 30 illustrates a certificate issuance 
response in accordance with a preferred embodiment. An approved 
bitmap for a VISA card is shown at 3000. Also a default payment 
holder 30 lO and a default payment holder name are provided with the 
certificate issuance. After the consumer aquires the payment 
instrument holder 3010. the payment instrument holder is 
25 immediately visible to him in his collection of payment instrument 
holders. Figure 31 illustrates a collection of payment instrument 
holders in accordance with a preferred embodiment. The predefined 
payment instrument holder 3100 is the same JOHN'S WALLET that 
was predefined based on defaults by the certificate issuance form. 



30 
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F.gure 32 illustrates the default payment instalment bitmap 3200 
associated with the predefined payment instrument holder 3 210 
resu lting f rom ^ co nsumer fiUing fa and obtaining ^ 
VISA card. 

Figu re 33 iHustrates a seated parent i„ strumem . fi|| 
N— for the c^hoider in . rarfMct ^ . Drefa7 ^ 
Next fme the payment instrument holder is opened in a payment 
con,«. the certttcate issuing authorty, approved indent bitmap 
can be used to sdect the payment instrument and utiU* it to make 
purchases. Figure 34 illustrates a coiTee purchase utilizing th e ncwly 
denned VISA card in accordance with a preferred embodiment of ^ 
invention. 
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CLAIMS 



What is claimed is: 
1 1. 



(a) 
(b) 
(cj 



A method for instrument certification (180-882) in a computer 
(1 10-138) with an attached display (138) connected to a network 
for receiving and transmitting network information (134), 
comprising the steps of: 

displaying a certification form for an instrument (1 10-138 180- 
882, 138, 2900-2934); 

detecting completion of the certification form (110-138. 180- 
882. 138, 2900-2934; and 

generating an instrument holder containing the instrument 
(110-138. 180-882, 138. 2900-2934, 3000-3020);. 

The method as recited in claim 1. wherein the instrument is 
represented in accordance with a bitmap defined by the 



1 certification form. 



The method as recited in claim 1, including the step of 
confirming authorization to determine if authorization should be 



3 granted to the instrument. 



I 

2 
3 



The method as recited in claim 1. including the step of providing 
lmkages to other displays providing additional functions 
associated with processing payment information. 



1 5. The method as recited in claim 1. including the step of 

2 prompting for an authorization code to authenticate a payment 

3 instrument. 
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1 6. The method as recited in claim 1, including the step of defining 

2 a payment method based on the certification form. 



1 7. The method as recited in claim 1, including the step of 

2 displaying an indicia representative of a payment instrument 

3 exceeding an authorized spending level. 

1 8. The method as recited in claim 1, including the step of 

2 displaying a list of each transaction that a particular payment 

3 instrument has been used for on the display. 

19. The method as recited in claim 1 , including the step of varying 

2 payment method processing based on the payment instrument 

3 selected in the payment instrument holder. 

1 10 



2 



I 11. 



1 12. 



The method as recited in claim 1, including the step of varying 
the payment instruments enabled for selection based on a 



3 particular merchant's practices. 



The method as recited in claim 1, wherein the payment 

2 instrument is represented in accordance with an issuer of the 

3 payment instrument's preferences. 



The method as recited in claim 1, wherein the payment 

2 instrument is represented in accordance with a bank 

3 preference. 
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1 3. An apparatus for instrument certification in a computer (110- 
138J with an attached display (138) connected to a network for 
receiving and transmitting network information (134); 
comprising: 

5 (a) the computer (1 10-138) under the control of software (180-882) 

6 displaying a certification form for a payment instrument (2900- 

7 2934); 

8 (b) an input device (124, 126) under the control of the computer 
(1 10-138) under the control of software (180-882) detecting 
completion of the certification form (2900-2934); and 

1 1 (c) the computer (1 10-138) under the control of software (180-882, 

12 2900-2934) generating a payment instrument holder containing 

13 the payment instrument (3000-3020). 



9 
10 



1 14. 

2 



I 15. 



1 16. 
2 

3 



The apparatus as recited in claim 13, wherein the payment 
instrument is represented in accordance with a bitmap defined 
by the certification form 



The apparatus as recited in claim 13, wherein the payment 

2 instrument is represented in accordance with user defined 

3 preferences. 



The apparatus as recited in claim 13, including said computer 
under the control of software displaying a list of each 
transaction that a particular payment instrument has been 



4 used for. 
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2 
3 

1 18. 

2 

3 

I 19. 

2 
3 



The apparatus as recited in claim 13, .ncluding said computer 
under the control of software varying payment processing based 
on the particular payment instrument selected. 

The apparatus as recited in claim 13. including said computer 
under the control of software varying the payment instruments 
based on a particular merchant's practices. 

The apparatus as recited in claim 13. wherein the payment 
instrument is represented in accordance with an issuer of the 
payment instrument's preferences on the display. 
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Wells Fargo 
Express 




HAWAII'S BEST ESPRESSO COMPANY 

1 Hawaiian Blend Decaf $7.50 
1 Hawaiian Blend $6.00 
1 Kona Wailapa Regular $18.99 
1 Maui ONO Farms Regular $25.99 

f 1 $8.00 
Tax $2.77 

Total $69.25 
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r 2080 ,-2082 
Date Time 



-2084 
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Instrument 



,-2086 
Item 



,-2088 r 2070 ,-2072 
Amount Paid Recieved 



& 6/ 10:30AM 


Visa: Family 


! Music CD J 12.37 


• 


Memo: Vivaldi's : 


Ref: 12A-923 


: Merchant: Tower Records : 




W 1020PM 


Visa: Family 


Car Registration renewal * 78.45 


:# # 


Memo: 


Ref:A31-001 


•Merchant: DMV : 


: 2090 — 


10:24PM 


Visa: Family 


t Utility Bill 1110.90 


:• • 


Memo: 


Ref: 123-09 


Merchant: PG&E • 




$j ,u/ 10:30AM; 


Visa: Family 


Music CD ; 12.37 


O • 


Memo: Beetles ! 


Ref: 13C-321 


Merchant: Tower Records : 




3/10/96 11:15AM: 


Visa: Family 


Hawaiian Blend Decaf : 69.25 


o • 
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Ref: 1231 
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3/KV96 11:55AM! 


Business Visa 


HP LaserJet 5L i 459.55 


o # 
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Ref: A1 1-012 


PC Connection : 




3/11/96 4:50PMi 
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RAM 16M SIMM i 249.10 


o « 
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Merchant: Fry's Electronics j 
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o o 
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| Report-Bob's Wallet 
Report Type: [Detail Sorted by Merchant 



-2540 

Merchant I Date Time 



Report- Bob's Wallet 

From Date: January 1st, 96 to March 3rd, 96 
2550 2560 2570 ^ 2580 



| Payment Method" 



Tower Records 1/21/96 10:21AM Visa Family: J12 20" 

Item: Music CD-Mozarf s 
Greatest Hits 10.00 
Shipping, Handling 1.80 
Sales Tax 0.40 



2590- 

Amount^ Paid j Received^ 



$12.20 



Tower Records 2/12/96 6:05PM Visa Family: 

Item: Music CD- 
Johannes's Best 10.00 
Shipping, Handling 1.80 

Sates Tax_ _ 0.40 

^ounl_Spent_at Tc^rRecords ~ "$24740 



Mac/s 



Mac/s 



1/21/96 10:21AM Visa: Family $1220 
Item: Desk Lamp 10.OO 
Shipping, Handling 1.80 
Sales Tax 0.40 



$12.20 



2/12/96 6:05PM Visa: Business 

Item: Lamy Pen 10.00 
Shipping, Handling 1.80 

Sales Tax 0.40 

Amount^Spenj_at Mac/s" "$24740 

Total AirountSpenf"" "$48780 
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Certificate Issuance Form 

Please enter information into all fields If a field does not apply to you, enter N/A 
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2900 -y 


JjCa^_Information 










1 










1 Card Number 


14417 2222 3333 9191 1 




1 








oono ^Expiry 


Date 


1 12/98 




r 




1 




































i Personal Information 










i 










(_Fjrst Name 


1 John 






1 








i Middle 


|F. 






i 










[Last 






1 Smith 










-i 










[Home Phone U 




Mil 222-3333 


1 (example:555 555-5555 








1 Social Security Number 1 111-22-3333 ] 


(example: 999-99-9999) 




-2908 
-2910 






i Date of Birth 




1 12/12/72 1 (month/day/year as 01/23/50) 


i 






[_Mother*s Maiden Name 


1 Jones 




) (for security purposes only) 










Address 
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■2906 




(Line ] 


1 141-22 Lone Drive 


1 








■ i 










Line2 


1 Kensineton 




















i Apt. # 
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1 






















,_Citv 


1 Palo Alto 




| State |CAl 


194025 1 
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2934 




(Jcon Preference 




1 Wallet ITI 












Password 




| **** 




1 










i Confirm Password 


I *#*# 
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Document Done 
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— 1 PayVVindow-John'sWato \Y\A 


L wallet | Plvmeflt , 




Card Name:! HrrtOsAVUa ~| 


Card Holder Name: | John F.Smith } 
Card Type:| Visa "| 


First USA Visa 


P^H^ } 




QUse as default payment method 
[ Add || Remove ) 




I lXx« I | Caned | 
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PayWrc*^^ Wafiet 



Payment Method 




First USA Visa 
l^ftange Payment Method) 



Order 



Merchant 



imp to Address 



HAWAII'S BIST ESPRESSO 
1 Kona Wailapa Regular $18.99 



SH 
Tax 



Total 

2Z 



$8 . 00 
SI. 12 



$28 .11 



1 A 2^ n % Totai Amount Show, Below 
According To The Card Issuer Agreement 

Amount: $28.11 
I Hereby Oigitafly Sign This Transaction 

n4q ^fiE5fl (Cancel 1» 
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